Sequenzdiagramm mit Ablauf der Prozesse -> (erledigt)
Klassendiagramme ->Oli 23.4 (erledigt)
Pflichtenheft ->23.4
1.Zielbestimmung -> Sebastian
1.1. Musskriterien
Aus dem Lastheft ergeben sich folgende Musskriterien
1.1.1 Funktionale Anforderungen
F01 Registrierung
Das Backend muss einen Webservice bereitstellen, über den es möglich ist, dass der neue Benutzer sich ein Benutzerkonto anlegt. Die vom neuen Benutzer eingegebenen Daten müssen durch das Backend persistent abgelegt werden. Der Client für das mobile Endgerät muss eine entsprechenden Maske anbieten, in der der Benutzer alle Pflicht -und optionalen Angaben für das Benutzerkonto eingeben kann. Die Anzeige zum Anlegen eines neuen Benutzerkontos muss die Applikation ermöglichen, ohne dass man sich an der Anwendung anmeldet. Folgende Informationen muss der Werbservice des Backends und die Maske des Clients bei der Erstellung des Benutzeraccounts verarbeiten können:
Feld
Beschreibung
Optional*
änderbar
Webservice
Client-GUI
Nickname
Benutzername/Profilname des Nutzers
Nein
x
x
Passwort
Anwendungspasswort des Nutzers:
Passwortbidlungsvorschift:
Mindestlänge: 5 Zeichen
1 Sonderzeichen muss enthalten sein
ja
x
x
Vorname
Vorname des Anwenders
x
ja
x
x
Name
Nachname des Anwenders
x
ja
x
x
Emailadresse
gültige Emailadresse des Nutzers
ja
x
x
Mobilfunknummer
Mobilfunknummer des Anwenders
ja
x
x
*Optional markierte Felder sind keine Pflichtfelder, und müssen von dem Benutzer bei der Registrierung nicht angegeben werden. Webservice und Client-GUI müssen diese Felder berücksichtigen.
1.1.2 F02 Anmeldung
Bevor ein registrierter Nutzer die Anwendung nutzen kann, muss er sich an der Anwendung mittels Nickname und Passwort oder Emailadresse und Passwort über den Client am Backend anmelden.
1.1.3 F03 Pflege von Profildaten
Das Backend muss einen Webservice zur Vefügung stellen, der eine Profildatenpflege ermöglicht. Über die GUI am Client wird die Pflege der Profildaten realisiert. Die Daten werden im Backend abgespeichert. Folgende Profildaten müssen gepflegt werden können:
Feld
Beschreibung
Pflichtangabe
Vorname
Vorname des Anwenders
Name
Nachname des Anwenders
Emailadresse
E-Mail Adresse des Anwenders
x
Passwort
Frei wählbares Passwort des Anwenders
Muss mindestens aus 5 Zeichen bestehen
Muss mindestens ein Sonderzeichen beinhalten
x
Mobilfunktnummer
Mobilfunknummer des Anwenders
x
Telefon
Zusätzliche Telefonnummer des Anwenders
PLZ
PLZ der Heimatadresse
Ort
Ort der Heimatadresse
Strasse
Strasse der Heimatadresse
Hausnummer
Hausnummer der Heimatadresse
Führerschein seit
Datum, seit dem der Anwender seinen Führerschein besitzt
Geburtstag
Geburtsdatum
Fahrzeug
Fahrzeugmarke und Modell (Frei Editierbar)
Raucher
Raucher (Ja, Nein)
Umwege
Nimmt der Anwender Umwege in Kauf (Ja, Nein)
Profilfoto
Profilfoto des Anwenders
1.1.4 F04 Mitfahrgelegenheit anbieten
Der Client bietet eine Oberfläche, mit der es möglich ist alle relevanten Informationen zu einer Mitfahrgelgenheit, die man anbieten möchte anzugeben. Das Backend bietet einen entsprechenden Webservice an, der die Daten entgegennehmen und verarbeiten kann. Folgende Daten können eingegeben werden:
Feld
Beschreibung
Pflichtangabe
Start
Adresse von wo der Fahrer die Reise antreten möchte
x
Ziel
Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.) oder Koordinaten
x
Reisebeginn
Datum des Reisestarts
Alternativ muss der Anwender hier auch Sofort auswählen können
x
Freie Sitzplätze
Anzahl möglicher Mitfahrer
x
Zur Unterstützung des Nutzers kann auf Fahrtangebote zurückgegriffen werden können, welche der Fahrer in der Vergangenheit angeboten hat. Als Startadresse kann der Nutzer seine aktuelle Position übernehmen. Die Position wird dann über die Geolocationsfunktionen des Endgerätes möglichst genau ermittelt.
1.1.5 F05 Mitfahrgelegenheit suchen/Mitfahrgesuch aufgeben
Die Android-Applikation und das Backend realisieren eine Funktion, die es ermöglicht, eine Mitfahrgelgenheit zu suchen. Im Client müssen dazu folgende Informationen angegeben werden:
Feld
Beschreibung
Pflichtangabe
Start
Adresse, von der der Mitfahrer abgeholt werden möchte
x
Ziel
Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.)
x
Reisebeginn
Datum/Uhrzeit des gewünschten Reisestarts oder Sofort
x
Die GUI unterstützt den Fahrtsucher bei der Eingabe der Daten anhand von Maskeneingaben aus der Vergangenheit. Auf Wunsch des kann die Startadrasse möglichst genau durch die Geolocationsfunktionen des mobilen Endgerätes ermittelt werden. Wird als Reisebeginn Sofort gewählt, wird als Startadresse immer die aktuelle Position des Nutzers angegeben. Hierzu wird auf Geolocationsfunktionen des mobilen Endgerätes zurückgegriffen.
Das Backend nimmt die Daten entgegen und wertet sie, sodass zur Suche passende Ergebnisse an den Client gesendet werden. Der Client stellt die Ergebnisse in einer Tabelle dar.
Folgende Informationen werden an den Client zurückgeliefert:
Feld
Beschreibung
Nickname
Nickname des Fahrtanbieters
Start/Position*
Startort des Fahrers
bei angetretener Fahrt aktuelle Position des Fahrers
Ziel
Ziel der angebotenen Reise des Fahrers
Reisedatum
Datum/Uhrzeit Fahrtantritt der Reise
Bewertung
Durchschnittsnote aller Bewertungen
Bewertungsanzahl
Anzahl der Bewertungen
*Es wird nicht die genaue Position des Fahrers übergeben, sodass Stalking erschwert wird.
1.1.6 Mitfahrgesuche anzeigen
Ein Fahrer, der eine Fahrt anbietet und schon eingegeben hat, kann die Möglichkeite nutzen, sich Mitfahrgesuche anzeigen zu lassen, die seiner geplanten Fahrt entsprechen. Für die Suche kann er zuvor eingeben, in welchem Umkreis um seine Startposition oder auch aktuelle Position nach Mitfahrerern gesucht werden soll. Die aktuelle Position wird durch Funktionen des Endgerätes ermittelt. Die Applikation realisiert eine Eingabemaske für den Fahrer um Mitfahrgesuche ermitteln zu können. Die Eingabemaske zeigt zunächst alle geplanten und noch nicht abgeschlossenen Fahrten des Nutzers. Hier kann der Nutzer die Fahrt aussuchen, für die er Mitfahrer suchen möchte. Die Eingabe der gewünschten Umkreissuche wird ermöglicht.
Die Daten der Anfrage werden an das Backend übermittelt. Der Webservice des Backendes muss die Daten vom Client verarbeiten können. Das Backend ermittelt anhand des aktuellen Datenbestandes alle Mitfahrgesuche, die zu der Suche des Fahrers passen und übermittelt das Ergebnis an den den Client.
Der Client stellt die empfangenen Daten in einer Tabelle dar. Folgende Daten werden je potentiellem Mitfahrer präsentiert
Feld
Beschreibung
Nickname
Nickname des Fahrtsuchers
Start/Position*
Startort des Fahrtsuchers
oder die aktuelle Position des Suchers
Ziel
Wunschziel Fahrtsuchers
Reisedatum
Datum/Uhrzeit Fahrtantritt der Reise
Bewertung
Durchschnittsnote aller Bewertungen
Bewertungsanzahl
Anzahl der Bewertungen
*Um Stalking zu erschweren wird die aktuelle Position des Fahrtsuchers ungenau angezeigt.
Der Nutzer kann sich Profilinformationen und Bewertungen, der User, die in der Ergebnismenge enthalten sind anzeigen lassen.
1.1.7 Mitfahrgelgenheit/Mitfahrgesuch löschen
1.1.7.1 Mitfahrgelegenheit löschen
Die GUI bietet die Möglichkeit angebotene, aber noch nicht angetretene Reiseangebote des eigenen Benutzers zu löschen. Das Backend bietet dazu einen passenden Webservice an. Auf Backendseite wird sichergestellt, dass der angemeldete Benutzer nur seine eigenen Angebote löschen kann.
Die GUI listet in einer Tabelle die noch nicht angetretenen Angebote auf. Folgende Information je Angebot werden dem Nutzer präsentiert:
Feld
Beschreibung
Start
Startadresse
Ziel
Zieladresse
Datum
Reisedatum
1.1.7.2 Mitfahrgesuch löschen
Die GUI bietet dem Nutzer die Möglichkeit eigene, eingegebene Reisegesuche zu löschen. Das Backend bietet dazu einen passenden Webservice an. Auf Backendseite wird sichergestellt, dass der angemeldete Benutzer nur seine eigenen Gesuche löschen kann.
Die GUI listet in einer Tabelle die eingegebenen Gesuche auf. Folgende Information je Gesuch werden dem Nutzer präsentiert:
Feld
Beschreibung
Start
Startadresse
Ziel
Zieladresse
Datum
Reisedatum
1.1.8 Benachrichtigung bei passenden Reisezielen / Fahrtangeboten
Wenn die Anwendung auf dem Endgerät läuft und der Benutzer angemeldet ist, fragt die Anwendung in regelmäßigen Intervallen bei dem Backend an. Hat der Nutzer ein Mitfahrgesuch oder eine Mitfahrangebot auf dem Server veröffentlicht, ermittelt der Server bei jeder Anfrage des Endgerätes, ob entsprechende Angebote oder Gesuche eingegeben wurden und übermittelt diese an das Endgerät. Ist die Anwendung auf dem Endgerät im Vordergrund, so werden die gefundenen Ergebnisse sofort auf dem Bildschirm angezeigt. Die Anzeige erfolgt in einer Tabelle wie in 1.1.5 und 1.1.6 beschrieben. Befindet sich die Anwendung im Hintergrund, so wird bei neu gefundenen Ergebnissen ein Symbol in der Statusleiste des Endgerätes angezeigt.
1.1.9 Bewertung abgebgen
Der Client bietet über eine Maske eine Bewertungsmöglichkeit. Auf der Bewertungsmaske werden alle anderen Nutzer angezeigt, für die man eine Bewertung abgeben kann. Je möglicher Bewertung wird eine Tabellenzeile angezeigt. Folgende Inhalte hat jede Zeile:
Feld
Beschreibung
Datum
Datum an dem die Fahrt stattgefunden hat
Start
Startort der Fahrt
Ziel
Zielort der Fahrt
Nickname
Nickname des zu bewertenden Nutzers
Rolle
Rolle des zu bewertenden Nutzers (Fahrer/Mitfahrer)
Durch Antippen der Zeile kann für diese Fahrt eine Bewertung eingegeben werden. Es wird eine weitere Maske geöffnet. In dieser Maske kann ein Freitext von 255 Zeichen eingegeben werden. Darüberhinaus kann eine Punktzahl (1-5) für die Bewertung angegeben werden, wobei 5 die höchste Wertigkeit darstellt.
Bedingungen für die Bewertung eines anderen Nutzers:
Eine Bewertung eines anderen Nutzers ist nur dann möglich, wenn der bewertende Nutzer und der zu bewertende Nutzer in unterschiedlichen Rollen an der gleichen Fahrgemeinschaft teilgenommen haben.
Bis zu 1 Monat nach Beendigung einer gemeinsamen Fahrt ist eine Bewertung möglich.
Das Backend liefert dem Client die Daten für die Auswahltabelle der Bewertung. Es liefert nur die Daten, die für den angemeldeten/anfragenden Nutzer relevant sind. Das Backend stellt einen Webservice zur Verfügung, der die Bewertungsinformationen für einen Nutzer (Freitext, Punktzahl) entgegennehmen kann. Die Bewertungsinformationen werden in der Datenbank abgelegt. Das Backend stellt sicher, dass die weiter oben beschriebenen "Bedingungen für die Bewertung eines anderen Nutzers" eingehalten werden.
1.1.10 Passwort zurücksetzen
Die GUI realisiert die Möglichkeit das Passwort eines Nutzers zurücksetzen zu lassen. Zur Rücksetzung wird die Emailadresse benötigt, mit welcher der Nutzer registriert ist.
Das Backend realisiert einen Webservice, der die Emailadresse von der Clientanwendung entgegennimmt. Im Backend wird dann ein neues Passwort generiert, bei den Userdaten abgespeichert und an die Emailadresse des Nutzers gesendet.
1.1.11 Historie eines Benutzers
Die GUI bietet einen Screen, mit dem es dem angemeldeten Nutzer möglich ist alle seine Mitfahrgesuche, Mitfahrangebote und genutzte Mitfahrgelgenheiten anzuzeigen. Je nach Displaygröße des Endgerätes wird nur ein Teil angezeigt. Durch klicken auf Mehr können weitere historische Einträge abgerufen werden. Aus diesem Screen heraus ist es möglich, nicht mehr gewünschte Angebote und Gesuche zu löschen (siehe 1.1.7).
Das Backend stellt der Clientanwendung die Daten bereit. Der Webservice des Backendes wird so implementiert, das nur die vom Client angefrangte Menge von historischen Einträgen übermittelt wird.
1.1.12 Administrative Eingriffe
Die administrativen Eingriffe erfolgen direkt auf der Datenbank. Es werden entsprechende Views, Funktionen und Skripte auf der Datenbank realisiert, um folgende Funbktionen zur Administration zu ermöglichen:
Deaktivierung eines Accounts
Aktivierung eines Accounts
Passwort Neugenerierung
Löschen von Bewertungen
1.1.13 Anzeige von Profilinformationen eines anderen Nutzers
Verschiedene Fälle der Anwendung erfordern es, dass ein Nutzer das Profil eines anderen Nutzers einsehen kann, z.B. bei dem Use-Case "Mitfahrgelgenheit suchen" muss der Benutzer sich die Profilinformationen des Fahrtanbieters anschauen können um zu entscheiden, ob er mit dem Fahrer mitfahren möchte und um Kontakt aufzunehmen.
Der Webservice der Anwendung sendet die Profilinformationen an den Client. Das Backend stellt sicher, dass eine Massenauslesung der Profilinformationen nicht möglich ist. Der Client kann nur die Profile abrufen, die innerhalb seines aktuellen Use-Cases für ihn relevant sind.
Beispiel Use-Case Fahrten suchen:
Der Mitfahrer sucht eine Mitfahrgelgenheit
Die Ergebnisse der Suche werden in einer Tabelle angezeigt.
Der Mitfahrer kann sich jetzt nur die Profile der anderen Nutzer anzeigen lassen, die in der Ergebnissmenge der vorherigen Suche enthalten sind.
In der Client-Anwendung werden über die GUI die Profilinformationen angezeigt.
Folgende Profildaten werden vom Backend gesendet und vom Client angezeigt:
Feld
Beschreibung
Nickname
Nickname des Anwenders
Vorname
Vorname des Anwenders
Name
Nachname des Anwenders
Emailadresse
E-Mail Adresse des Anwenders
Mobilfunktnummer
Mobilfunknummer des Anwenders
Führerschein seit
Länge des Führerschein
Alter
Alter des Fahrers
Fahrzeug
Fahrzeugmarke und Modell (Frei Editierbar)
Raucher
Raucher (Ja, Nein)
Profilfoto
Profilfoto des Anwenders
1.1.14 Anzeige von Bewertungen
Verschiedene Fälle der Anwendung erfordern es, dass ein Nutzer die Bewertungen eines anderen Nutzers einsehen kann, z.B. bei dem Use-Case "Mitfahrgelgenheit suchen" dienen diese als Entscheidungshilfe für den Mitfahrer, ob er mit einem Fahrer eine Fahrgemeinschaft eingehen möchte
Der Webservice der Anwendung sendet die Bewertungen des entsprechenden Nutzers an den Client. Das Backend stellt sicher, dass eine Massenauslesung der Bewertungen nicht möglich ist. Der Client kann nur die Bewertungen abrufen, die innerhalb seines aktuellen Use-Cases für ihn relevant sind.
Beispiel Use-Case Fahrten suchen:
Der Mitfahrer sucht eine Mitfahrgelgenheit
Die Ergebnisse der Suche werden in einer Tabelle angezeigt.
Der Mitfahrer kann sich jetzt nur die Bewertungen der anderen Nutzer anzeigen lassen, die in der Ergebnissmenge der vorherigen Suche enthalten sind.
In der Client-Anwendung werden über die GUI die Bewertungen angezeigt.
Folgende Bewertungsinformationen werden vom Backend gesendet und vom Client angezeigt:
Feld
Beschreibung
Nickname
Nickname des Nutzers auf den die Bewertung zutrifft
Durchschnittsnote
Durchschnittsnote aller Bewertungen
Gesamtanzahl
Gesamtanzahl der Bewertungen
0.n Einzelnote
Einzelnote je Bewertung
0.n Bewertungsfreitext
Freitext je Bewertung
0.n Datum
Datum der Bewertung
Rolle
Fahrer oder Beifahrer bei dieser Bewertung
0.n: ein Nutzer kann beliebig viele Bewertungen haben. Das Backend überträgt zunächst die aktuellesten. Um Datenvolumen zu sparen werden nicht alle Bewertungen übertragen. In der Anfrage des Clients kann die Anzahl der Bewertungen und die "Seite" mitgegeben werden. Wird keine Anzahl mitgegeben, so lierfert das Backend die 5 aktuellsten Bewertungen. Unter Seite ist zu verstehen, dass auch ältere Bewertungen abgerufen werden können.
Beispiel:
Anzahl von Bewertungen pro Seite = 7
Seite
Bewertungen
1
1 - 7
2
8 - 14
6
43 - 49
1.1.2 sonstige Musskriterien
1.1.2.1 Standardschnittstellen
Das Backend verwendet zur Kommunikation mit dem Client standardisierte Protokolle und Schnittstelle, damit auch andere mobile Endgeräte als Android angebunden werden können.
1.1.2.1 Bedienungsoberfläche
Die Bedienungsoberfläche wird selbsterklärend gestaltet, eine Bedienung mittels Touchscreen wird ermöglicht.
1.2. Wunschkriterien 1.2.1 Ameldung an der Anwendung über Facebook 1.2.2 Posting vo nFahrtangebote und –gesuche aufder Facebookseite des jeweiligen Users 1.2.3 Aktualisierung der Position des Nutzers auf der zugehörigen Facebookseite
1.2.4 Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
1.2.5 Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden
1.3. Abgrenzungskriterien
1.3.1 Oberfläche für Geräte der Smartphoneklasse
Die Oberfläche wird für Androidgeräte mit einem Display von bis zu 5 Zoll entwickelt. Die Anwendung ist auf Tablet-PC mit Android-Betriebssystem lauffähig, aber wird nicht für die größeren Displays optimiert.
1.3.2 Einsatzort
Die Applikation und das Backend werden für den Einsatz in Deutschland entwickelt.
2. Produkteinsatz
Im folgenden Abschnitt wird auf den Produkteinsatz der Applikation eingegangen. Dabei wird im Anwendungsbereich der Zweck der Applikation erläutert. Bei den Zielgruppen geht es darum zu erläutern, welche Personen mit welchen Qualifikationen die Anwendung nutzen sollen und bei den Betriebsbedingungen geht es darum, diese zu erläutern.[[#_ftn1|[1]]]
Die Anwendung wird von einzelnen Personen zur Suche von Mitfahrgelegenheiten und zum Bekanntmachen einer Fahrt genutzt. Dem Anwender wird es so ermöglicht, Kosten zu sparen, indem er sich an einer Fahrt beteiligt oder selbst eine Fahrt tätig und hier andere Nutzer mitnimmt.
2.2. Zielgruppen
Zur Ziel gehören, die im Lastenheft erörterten Personen. Die Anwender sollten ein Smartphone mit Internetzugang und dem Betriebssystem Android besitzen. Weiterhin sollten Kenntnisse im Umgang mit dem Umgang von Smartphone Applikationen vorhanden sein. Da die Software in deutscher Sprache umgesetzt wird, sollte der Anwender diese Sprache beherrschen.
2.3. Betriebsbedingungen
Hinsichtlich der Betriebsbedingungen orientiert sich die Anwendung an den üblichen Bedingungen von Smartphone Applikationen und Webservices:[[#_ftn1|[1]]] - Betriebsdauer: 24 Stunden täglich - Wartungsfrei - Keine ständige Beobachtung des Systems nötig
Für die Android Endgeräte wird die Betriebssystemversion 2.1 Codename Eclair verwendet. Durch die Verwendung dieser Version können laut der unten zu sehenden Grafik bis zu über 90% aller Android Usern durch die AppFahrt unterstützt werden. Somit würde im Gegensatz zur Implementiertung für eine höhere Androidversion wie beispielsweise 2.3 ein höhere Abdeckung möglich sein, da Apps grundsätzlich abwärtskompatibel sind.
Im Gegensatz zur Version 2.2 weist die aktuelle Version 2.3 Codename Gingerbread keine für diese Applikation nennenswerte Vorteile, sodass diese ausgeschlossen werden kann.
3.1.2 Oberfläche
Um die geforderten Anforderungen benuterfreundlich zu realisieren werden folgende Oberflächen in der Android App realisiert.
App Start
ProfilerstellenFacebook Login
Facebook Aktionen - Login
Map
Map - Fahrt antreten
Map - Fahrt suchen
Map - Fahrt bewerten
Detailierte Beschreibung sowie Abbildungen erfolgen im Kapitel Benutzungs- und Systemschnittstellen.
3.1.3 Verwendete Softwarekomponenten
Für die Entwicklung der clientseitigen Applikation werdne folgende Komponenten eingesetzt:
als Programmiersprache Java
als Entwicklungsumgebung Eclpise Helios Service Release
Andorid SDK für Eclipse
Android Emulator (enthalten im Android SDK)
Facebook API
OpenStreetMap - Osmdroid Projekt
CloudMade Registrierung
3.2. Hardware
Die Applikation ist so konzepiert, dass diese auf allen Smartphones mit der Betriebssystemversion 2.1 Codename Eclair lauffähig ist. Grundsätzlich ist die haupt Androidplattform die ARM Architektur
Der größte Vorteil der ARM Architektur ist die geringe Leistungsaufnahme, wodruch diese Architektur insbesondere für mobile Endgeräte eingesetzt wird. (Quelle http://en.wikipedia.org/wiki/Android_%28operating_system%29#Hardware_running_Android)
3.4 Voraussetzung für die Nutzung der Applikation
Für die Nutzung der Applikation ist sowohl eine Internetverbindung als auch GPS Verbindung zwingend notwendig. Die Internetverbindung ist sowohl für die Verbindung zum Webserver der Anwendung notwendig als auch für die Verbindung zu den Servern von CloudMade und OpenStreetMap.
Durch eine aktive GPS Verbindung ist die Ermittlung der aktuellen Position möglich. Weiterhin werden die GPS Koordinaten serverseitig benötigt, um die notwenidgen Berechnungen durchführen zu können und potentielle Mitfahrer und Fahrer zu verbinden.
3.4. Produkt – Schnittstellen
Die clientseitige Applikation verfügt über Webserviceschnittstellen, die für die Kommunikation zum Webserver dienen. Darüberhinaus ist eine Schnittstelle zum Facebookdienst vorhanden. Die Anwendung immplementiert die Facebook API und greift über das Internet auf die Facebook Webserver zu und ermöglicht so die Nutzung der zu Verfügung gestellten Services.
Weiterhin nutzt die clientseitige Anwendung den Webservice von Cloudmade und Open Street Map für die Darstellung der aktuellen Positon auf der Karte.
4. Akteure und Anwendungsfälle
4.1 Akteure
Für das System AppFahrt werden vier Akteure modelliert. Die Akteure Mitfahrer, Fahrer und Adminstrator sind eine Generalisierung des Akteurs Anwender, der einen generische Akteur darstellt.
Nachfolgend eine Kurzbeschreibung der vier Akteure:
Name
Kurzbeschreibung
Anwender
Stellt einen Rumpf-Akteur dar, von dem alle weiteren Akteure abgeleitet werden.
Fahrer
Ein Fahrer bietet im System Fahrten an. Ein Fahrer kann prinzipiell auch ein Mitfahrer sein, jedoch nicht bei der gleichen Fahrt.
Mitfahrer
Ein Mitfahrer sucht nach Fahrten bei denen er mitfahren kann. Ein Mitfahrer kann prinzipiell auch ein Fahrer sein, jedoch nicht bei der gleichen Fahrt.
Administrator
Ist eine übergeordnete Instanz mit besonderen Berechtigungen.
4.2 Use Case Überblick
Im weiteren Verlauf der Spezifikation und Entwicklung werden zur Wahrung des Projektrahmens nur die Anwendungsfälle des Pakets"Fahrt planen und durchführen" weiter betrachtet. Die charakteristischen Funktionen des Systems AppFahrt sind in diesem Paket enthalten.
Anwendungsfälle der weiteren Pakete Userprofil verwalten und Administration enthalten Funktionalitäten, so z.B. der Anwendungsfall Userprofil bearbeiten, die in herkömmlichen IT-Systemen enthalten sind und an dieser Stelle nicht detailiert beschrieben werden müssen, wenngleich sie für die Umsetzung des Gesamtsystems notwendig sind.
4.2.1 Fahrt planen
Name und Identifier
1.1 Fahrt planen
Beschreibung
Ein Fahrer plant eine Fahrt und bietet Mitfahrern die Möglichkeit sich für diese Fahrt anzumelden.
Beteiligte Akteure
Fahrer
Status
final
Verwendete Anwendungsfälle
-
Auslöser
-
Vorbedingungen
Fahrer hat ein Userprofil
Fahrer ist am System angemeldet.
Invarianten
Ergebnis
Fahrt ist angelegt und für Mitfahrer sichtbar.
Standardablauf
1. Der Fahrer gibt den Startpunkt der Fahrt ein.
2. Der Fahrer gibt den Endpunkt der Fahrt ein.
3. Das System macht einen Vorschlag für den Fahrpreis. Der Fahrer gibt den Fahrpreis an.
4. Der Fahrer gibt einen Starttermin der Fahrt an (Datum und Uhrzeit).
5. Der Fahrer gibt die Anzahl der freien Plätze an.
6. Der Fahrer veröffentlicht die Fahrt.
7. Das IT-System bietet die Möglichkeit eine Rückfahrt einzugeben.
Alternative Ablaufschritte
1. Der Fahrer gibt seine aktuelle GPS-Position als Startpunkt ein.
4. Der Fahrer gibt als Starttermin "Sofort" ein.
Hinweise
-
Änderungsgeschichte
28.03.2011, OW Ersterstellung
4.2.2 Mitfahrwunsch angeben
Name und Identifier
1.2 Mitfahrwunsch angeben
Beschreibung
Ein Mitfahrer sucht eine Mitfahrt. Dabei können die folgenden Fälle unterschieden werden.
Standardablauf: Es existiert bereits eine passende Fahrt, die der Mitfahrer auswählen kann.
Alternative Ablaufschritte: Es gibt keine passende Fahrt. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch, mit dem Ziel, dass sich ein Fahrer dazu findet.
In diesem Use Case können auch Mitfahrwünsche für bereits aktiven Fahrten (D.h. die Fahrt ist bereits angetreten) angegeben werden. Die Anzeige bzw. Auswahl von aktiven Fahrten ist abhängig von den einzugebenen Suchkriterien (Abfahrtort, Abfahrttermin) einer Fahrt.
Beteiligte Akteure
Mitfahrer.
Status
final
Verwendete Anwendungsfälle
-
Auslöser
-
Vorbedingungen
Mitfahrer hat ein Userprofil.
Mitfahrer ist am System angemeldet.
Invarianten
Ergebnis
Der Mitfahrer hat seinen Mitfahrwunsch veröffentlicht. Der Fahrer kann den Mitfahrwunsch akzeptieren.
Standardablauf
1. Der Mitfahrer sucht nach einer Fahrt. Suchkriterien sind Startpunkt, Endpunkt und Uhrzeit. Die freien Plätze einer Fahrt werden dabei berücksichtigt.
2. Das IT-System liefert den Suchkriterien entsprechende Fahrten zur Auswahl zurück.
3. Der Mitfahrer wählt eine Fahrt aus.
4. Der Mitfahrer äußert seinen Mitfahrwunsch gegenüber dem Fahrer.
Alternative Ablaufschritte
2. Das IT-System liefert kein passendes Ergebnis. Der Mitfahrer kann seine Suchkriterien anpassen.
3. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch mit den in den Suchkriterien angegebenen Attributen (Startpunkt, Endpunkt, Termin).
4. Der Mitfahrer gibt einen Fahrpreis an.
4. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch. Der Mitfahrwunsch ist für Fahrer sichtbar.
Hinweise
1. Als Startpunkt können Startpunkt kann "Hier" angegeben werden. Dies ist die aktuelle GPS-Position. Als Startzeitpunkt kann "Jetzt" angegeben werden. Dies ist die aktuelle Uhrzeit.
Änderungsgeschichte
28.03.2011, OW Ersterstellung.
4.2.3 Mitfahrwunsch annehmen
Name und Identifier
1.3 Mitfahrwunsch annehmen
Beschreibung
Ein Fahrer hat seine Route geplant. Ein oder mehrere Mitfahrer haben einen Mitfahrwunsch gegenüber angegeben. Der Fahrer bestätigt den Mitfahrwunsch.
Dabei ist es unerheblich, ob die Fahrt noch geplant oder bereits aktiv ist.
Beteiligte Akteure
Fahrer, Mitfahrer
Status
final
Verwendete Anwendungsfälle
-
Auslöser
Mitfahrwunsch wurde angegeben.
Vorbedingungen
Mitfahrwunsch liegt vor
Fahrer hat ein Userprofil.
Fahrer ist am System angemeldet.
Invarianten
-
Ergebnis
Mitfahrwunsch ist angenommen. Mitfahrer wird über die Annahme des Mitfahrwunschs informiert.
Standardablauf
1. Dem Fahrer werden Mitfahrwünsche angezeigt.
2. Der Fahrer kontaktiert den Mitfahrer.
3. Der Fahrer bestätigt den Mitfahrwunsch. Die Anzahl freier Plätze wird aktualisiert.
4. Der Mitfahrer erhält eine Bestätigung der Mitfahrt per Email/ SMS.
Alternative Ablaufschritte
3. Der Fahrer lehnt den Mitfahrwunsch ab. Es erfolgt keine weitere Aktion bezüglich des abgelehnten Mitfahrwunsches. Der Fahrer wählt einen weiteren Mitfahrwunsch aus und kann wiederum über den Mitfahrwunsch entscheiden.
Hinweise
Die Anzeige der Mitfahrwünsche kann Mitfahrwünsche enthalten, die entlang der aktiven Fahrt liegen oder die auf der vor Fahrtantritt geplanten Route liegen.
Änderungsgeschichte
28.03.2011, OW Ersterstellung.
4.2.4 Fahrt antreten und tracken
Name und Identifier
1.4 Fahrt antreten und tracken
Beschreibung
Eine geplante Fahrt wird gestartet. Während der Fahrt wird die Position des Fahrers erfasst und aktualisiert.
Beteiligte Akteure
Fahrer, Mitfahrer
Status
final
Verwendete Anwendungsfälle
Auslöser
Route wurde geplant. Starttermin ist eingetreten.
Vorbedingungen
Route ist geplant.
Fahrer hat ein Userprofil
Fahrer ist am System angemeldet.
Invarianten
Ergebnis
Fahrt ist aktiv und wird getrackt.
Standardablauf
1. Mitfahrer treffen Fahrer am vereinbarten Startpunkt zur vereinbarten Startzeit.
2. Fahrer aktualisiert die Anzahl der freien Plätze.
3. Fahrer startet seine Fahrt.
4. Die Position des Fahrers wird geändert und zyklisch aktualisiert.
5. Der Fahrer beendet die Fahrt.
Alternative Ablaufschritte
Schritt 1 ist optional. Der UC kann auch mit Schritt 2 beginnen.
Hinweise
Beginnt ein Fahrer seine Fahrt, wird seine aktuelle Position an den Server gesendet, wenn er noch Kapazitäten frei hat
Während oder nach einer Fahrt können sich die Fahrer und Mitfahrer gegenseitig bewerten. Mitfahrer sollen sich jedoch nicht gegenseitig bewerten können.
Beteiligte Akteure
Fahrer, Mitfahrer
Status
final
Verwendete Anwendungsfälle
Auslöser
Fahrt ist angetreten oder beendet
Vorbedingungen
Fahrt ist geplant.
Fahrer hat ein Userprofil
Fahrer ist am System angemeldet.
Invarianten
Ergebnis
Fahrer und Mitfahrer einer Fahrt wurden bewertet
Standardablauf
1. Fahrer wählt eine Fahrt aus.
2. Fahrer klick auf "Fahrt bewerten".
3. Fahrer vergibt Bewertungspunkte für einen Mitfahrer.
4. Fahrer schreibt als Bewertung einen Freitext.
5. Fahrer klickt auf "Bewertung absenden"
Alternative Ablaufschritte
-
Hinweise
Bewertung erfolgt genauso für einen Mitfahrer.
Änderungsgeschichte
26.04.2011, OW Ersterstellung.
4.2 Domänen-Klassendiagramme ->Marcel + Sebastian
Das nachstehende Klassendiagramm stellt alle Gegenstände dar, die im Rahmen der geforderten Anwendungsfälle Verwendung finden. Anhand der vorgegebenen Sturktur mit Klassen und Attributen soll die Entwicklung der Anwendung durchgeführt werden. Die aufgezigten Klassen samt Attributen sollen als Basis für den Entwurf genutzt werden, in dem weitere Attribute und vor allem Methoden an den Klassen ergänzt werden müssen, die für die Anwendung benötigt werden.
4.3 Benutzungs- und Systemschnittstellen -> Aleks
4.3.1 Android Applikation - Gui
App Start
Beim erstmaligen Start der Applikation wird das AppFahrt Logo dargestellt. Das Logo soll die Applikation einleiten. Nach einigen Sekunden wird das Logo ausgebledet und der Login Screen erscheint. Das Logo erscheint wie bereits erwähnt beim erstmaligen Start der Anwendung. Befindet sich die Anwendung bereits im RAM Speicher des Smartphones erscheint sofort das Login Screen. Wird die Anwendung jedoch vom Android Betriebssystem aus dem RAM entfernt und die Anwendung zum späterem Zeitpunkt gestartet, so wird das Logo wieder dargestellt.
Login Screen
Der Login Screen ermöglich wie der Name bereits aussagt das Einloggen eines Benutzers in die Applikation. Hierfür trägt der Anwender seine Email und Passwort in die entsprechenden Felder ein. Die Anmeldedaten werden verefiziert und beim erfolgreichen verefizieren der eingegebenen Daten wird die Map angezeigt. Sind die eingegebenen Daten jedoch fehlerhaft, wird durch eine Meldung der User darauf hingewiesen und die Map wird nicht dargestellt.
Enthält der Benutzer noch kein Useraccount für diese Applikation kann dieser durch das auswählen des Profil erstellen Buttons ein Profil für die Applikation anlegen. Weiterhin hat der Anwender die Möglichkeit sich durch sein Facebook Account an der Anwendung anzumelden. Zum Facebook Login Screen gelangt der Anwender durch das klicken auf den Facebook Button.
Profilerstellen
Falls noch kein Profil für die Applikation vorhanden ist, kann der Anwender wie bereits erwähnt ein Profil erstellen. Der Kontakdaten Screen enthält Eingabefelder für die Eingabe notwendiger Informationen für das Profil.
Welche Pflichtfelder befüllt werden müssen, um die einmalige Profilerstellung erfolgreich abzuschließen, kann dem Kaptitel 1.1.1 Funktionale Anforderung entnehmen.Wird ein Pfichtfeld nicht befüllt so erscheint eine Meldung mit dem Pflichtfeld / Pflichtfeldern die noch auszufüllen sind, um das Profil erfolgreich zu erstellen.
Facebook Login
Möchte man sich mit deinem Facebook Account an der Applikation anmelden, so drückt der Benutzer auf das Facebook Icon Button. Nach dem Klicken verändert sich die Farbe des Icons von blau nach grau. Anschließend erscheint der Facebook Login Screen.
Facebook Aktionen - Login
Hier hat der User zunächst die Möglichkeit sich durch das klicken auf den Login Button mit seinem Facebook Logindaten anzumelden.
Es erscheint der Facebook-Anmeldung Bildschirm, wo der Anwender seine Facebook Logindaten eingeben kann und anschließend mit Anmelden bestätigen.
Im nächsten Screen, dem Anfrage für Genehmigung Bildschirm, wird der Anwender aufgefordert durch das Klicken auf den Button Zulassen einige Berechtigung für die Anwendung freizugen. Diese Berechtigung sind notwendig, damit die Anwendung unter anderem auf die Emailadresse des Anwenders zugreifen kann, um diese in die eigene Datenbank abzuspeichern, ähnlich wie beim erstellen eines Profils für die Anwendung.
Nach dem erfolgreichen Anmelden am Facebook ist der Anwender in der Lage, durch das klicken auf den Button Post beispielsweise seine geplante Fahrt auf seine Pinwand zu posten. Seine Facebook Freunde sowie die Freunde von AppFahrt bekommen dadurch im Voraus mit welche Fahrt der Anwender plant und können somit den Anwender direkt kontaktieren um ggf. mitfahren zu können.
Map
Nachdem erfolgreichen anmelden an Applikation öffnet sich der Map Screen. Es wird die aktuelle Position des Anwenders angezeigt. Die aktuelle Position wird an Hand der GPS Daten ermittelt. Durch das klicken auf die Manü Taste des jeweiligen Smartphones öffnen sich in der unteren Leiste view Menüoptionen.
Back - Durch das klicken auf Back gelangt der Anwender wieder zurück auf den Login Screen.
Fahrt erstellen... - Durch das klicken auf Fahrt erstellen...gelangt der User in den Fahrtantritt Screen
Fahrt suchen...- Durch das klicken auf Fahrt suchen...gelangt der User in den Fahrtgesuch Screen
Fahrt bewerten...- Durch das klicken auf Fahrt bewerten...gelangt der User in den Fahrtbewerten Screen
Map - Fahrt antreten
Wie bereits erwähnt durch das klicken auf den Button Fahrt erstellen... erscheint das Fahrtantritt Screen. Hier kann der Anwender eine spontante Fahrt erstellen. Kapitel 1.1.4 Kann man die Pflichtfelder hierfür entnehmen.
Map - Fahrt suchen
Wie bereits erwähnt durch das klicken auf den Button Fahrt suchen... erscheint das Fahrtgesuch Screen. Hier kann der Anwender nach Fahrten suchen. Kapitel 1.1.5 Kann man die Pflichtfelder hierfür entnehmen.
Map - Fahrt bewerten
Durch das klicken auf den Button Fahrt bewerten... erscheint der Fahrtbewertung Screen. Hier kann hat der Anwender die Möglichkeit seine Fahrten zu bewerten gemäß der Anforderung im Kapitel 1.1.9.
4.3.2 Android Applikation - Schnittstellen
Android Applikation enthält Schnittstellen zu
Facebook - diese Schnittstelle wird verwendet, um das Einloggen des Anwenders mit Facebook zu ermöglichen
Webservce der Applikation - diese Schnittstelle dient dem grundsätzlichen Datenaustausch
CloudMade - durch dises Schnittstelle erhält die Applikation Geodaten und kann darüber hinaus Routinfunktionen ausführen
4.3.3 Webserver - Schnittstellen
Der Webserve enthält Schnittstellen zu
Facebook - diese Schnittstelle dient der Abfrage von Benutzerinformationen von Facebook
Android Smartphones - diese Schnittstelle dient dem grundsätzlichen Datenaustausch zwischen Server und Clients
DB Server - diese Schnittstelle dient der Ausführung der CRUD-Operationen mit der Persistenzschicht des Webservers
5.Nicht-Funktionale Anforderungen
5.1 Qualitätsanforderungen -> Aleks(test) + Marcel (technische qualitätssicherung z.b. Zeiten)
TODO:Hier sollten wir auch auf Tests eingehen
5.1.1 Performance
Anhand von reproduzierbaren Messungen soll die Performance bewertet werden. Folgende Anwendungsfälle müssen in besteimmten Zeitrahmen durchgeführt werden können:
Fall
Max. Sekunden Ladezeit
Start
5
Anmeldung
5
Mitfahrgesuche anzeigen
5
Mitfahrgelegenheit anbieten
5
Mitfahrgelegenheit suchen
5
Dies sind die elementaren und zeitkritischen Anwendungsfälle der Anwendung und müssen im Rahmen der angegeben Ladezeigt durchgeführt werden können. Die ist immer ab dem Zeitpunkt zu betrachten, an dem der Anwender seine Daten oder eine Anfrage absendet. Des Weiteren beziehen sich die Ladezeiten auf die Übermittlung der ermittelten Daten an das Endgeärt und schließen die visuelle Darstellung nicht mit ein.
Die Verarbeitung der Daten auf dem Client darf maximal zwei Sekunden in Anspruch nehmen.
5.1.2 Skalierbarkeit
Da die Akzeptanz und somit die Anzahl der gleichzeitig aktiven Benutzer nicht absehbar ist, muss das Backend skalierbar ausgelegt sein. Das Backend muss minimal Anfragen von 100 aktiven Nutzern in der definierten Antwortzeit bearbeiten können. Das System muss flexibel ausgelegt sein, so dass durch hinzunahme weiterer Hardware, Anfragen von bis zu 10.000 aktiven Nutzern in der vorgegebenen Antwortzeit bearbeitet werden können.
Um Anschaffungs- und Betriebskosten zu sparen soll das System zunächst für 100 aktive Nutzer ausgelegt sein.
Durch die definierten Anforderungen an Performance und Skalierbarkeit werden im Laufe der Entwicklung und der Integrationstests die Anforderung an die Hardware, das Sizing, abgeleitet. Hier wird die Prognose des Wachstums mit einfließen.
Wird ein Performance-Engpass am Client festgestellt, so ist durch einen dynamischen Prozess sicherzustellen, dass ausreichend Ressourcen für diese Anwendung vom Clientbetriebssystem reserviert werden. Ist das beschaffen zusätzlicher Ressourcen vom Clientbetriebssystem nicht möglich, so ist der Benutzer durch eine Meldung über den Ressourcen-Engpass zu informieren.
5.1.3 Verfügbarkeit
Im Lastenheft ist gefordert, dass die Anwendung als hochverfügbar ausgelegt sein muss. In diesem Zusammenhang muss bei der Auswahl des Backendsystems darauf geachtet werden, dass die einzelnen Komponenten diese Anforderung erfüllen. Zu diesem Zweck sollte die Serveranwendeung auf mehreren Instanzen zur Verfügung stehen. Der Client hat dann die Möglichkeit über einen Loadbalancer auf den Server zuzugreifen.
Für etwaige Systemausfälle müssen Backups der Produktivdaten gesichert werden. Das Backup muss sämtliche Applikationsdaten bis zu dem entstandenen Fehlerfall wiederherstellen können.
5.2 Sicherheit
Sämtliche Daten der Anwendung müssen vor unbefugtem Zugriff geschützt sein. Zu diesem Zweck muss die Übertragung von personenbezogenen Daten zwischen dem Client und dem Backend verschlüsselt erfolgen. Daten dürfen nicht Massenweise ausgelesen werden können. Böswillige Attacken werden unterbunden.
Das Backend muss vor eventuellem Hackerangriffen geschützt sein. Denial of Service Attacken müssen verhindert werden.
Es muss sichergestellt werden, dass der Client ausschließlich mit den definierten Endpunkten kommuniziert. Man in the middle Attacken dürfen nicht möglich sein.
5.3 Testkonzept
Im Kapitel Abnahmekriterien des Lastenhefts wird gefordert, dass die nicht- und funktionale Anforderungen durch Tests nachgewiesen werden.
Anwendungsfall
F01 Registrierung
Szenario
Registrierung eines neuen Benutzers
Voraussetzung
Der Benutzer ist noch nicht am System registriert. Eine Anmeldung mit der Emailadresse ist am System nicht möglich.
Eingangsparameter
Pflichtparameter werden in der ensprechenden Maske befüllt.
Durchzuführende Aktion
Anwender führt eine Registierung durch in dem er ein Profil in der entsprechenden Maske erstellt.
Erwartetes Ergebnis
Nach dem alle Pflichtfelder bedient wurden, wird eine neues Profil erstellt. Das Einloggen mit diesem Profil ist nun möglich.
Tatsächliches Ergebnis
Anwendungsfall
F02 Anmeldung
Szenario
Clientseitige Anmeldung an der Applikation
Voraussetzung
Anwender ist am System Registriert.
Eingangsparameter
Email und Passwort das bei der Registrierung vergeben wurden
Durchzuführende Aktion
Anwender meldet sich am System durch Eingabe seiner Emailadresse und des Passwortes in der entsprechenden Maske an.
Erwartetes Ergebnis
Ist die Eingabe falsch oder das Benutzerprofil ist nicht vorhanden, erhält der Anwender eine entsprechende Meldung. Andernfalls gelangt der Benutzer auf den nächsten Screen nachdem die Daten durch den Server erfolgreiche verifiziert wurden.
Tatsächliches Ergebnis
Anwendungsfall
F03 Pflege von Profildaten
Szenario
Clientseitige Pflege von Profildaten
Voraussetzung
Anwender ist am System Registriert und Profil ist vorhanden
Eingangsparameter
Ensprechend der Anfroderung F3 können Angaben geändert werden
Durchzuführende Aktion
Profildaten die in der Anforderung F03 markiert sind werden nacheinander geändert
Erwartetes Ergebnis
Die Ändrung der markierten Profildaten ensprechend der Anforderung F03 ist möglich. Andere Daten können nicht geändert werden.
Tatsächliches Ergebnis
Anwendungsfall
F04 Mitfahrgelegenheit anbieten
Szenario
Clientseitige Möglichkeit Mitfahrgelegenheiten an den Server zu übermitteln
Voraussetzung
Anwender ist am System Registriert
Eingangsparameter
Ensprechend der Anfroderung F04 kann der Anwender eine Fahrt anbieten.
Durchzuführende Aktion
Der Anwender ruft den entsprechenden Screen auf und bedient die Eingabefelder. Das erstellte Angebot wird anschließend automatisch per Webservice an den Server übermittelt
Erwartetes Ergebnis
Der Anwender erhält eine positive Meldung, dass das erstellte Fahrangebot an den Server übermittelt wurde
Tatsächliches Ergebnis
Anwendungsfall
F05 Mitfahrgelegenheit suchen
Szenario
Clientseitige Möglichkeit Mitfahrgelegenheiten zu suchen.
Voraussetzung
Anwender ist am System Registriert
Eingangsparameter
Ensprechend der Anfroderung F05 kann der Anwender am Client Fahrangbote suchen.
Durchzuführende Aktion
Der Anwender ruft den entsprechenden Screen auf und bedient die Eingabefelder. Der erstellte Gesuch wird an den Server per Webservice übermittelt.
Erwartetes Ergebnis
Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind.
Anwender ist am System Registriert. Mitfahrgelegenheiten zum gesuchten Ziel und/oder Umkreis sind vorhaden
Eingangsparameter
eine detailierte Ansicht der dargestellten Fahrangebote ist durch das klicken auf ein ensprechendes Angebot möglich.
Durchzuführende Aktion
Der Anwender gibt im vorherigen Screen seine Suchparameter ein. Diese werden per Webservice an den Server übermittelt. Das Ergebnis wird an den Client wieder übertragen und tabellarisch dargestellt. Weitere Informationen ensprechend der Anfordernung können durch das klicken auf das jeweilige Angebot detalierter eingesehen werden.
Erwartetes Ergebnis
Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind.
Tatsächliches Ergebnis
Anwendungsfall
F07 Mitfahrgelegenheit/Mitfahrgesuch löschen
Szenario
Clientseitige Möglichkeit bereits eingetragene Gesuche und Angebote löschen
Voraussetzung
Anwender ist am System Registriert. Fahrangebot /Mitfahrgelegenheitsgesuch ist bereits im System eingestellt
Eingangsparameter
Anwender kann seine erstellten Fahrangebote oder Gesuche entfernen, falls diese noch nicht angetreten wurden. Hierfür wählt der Anwender das entsprechende Abgebot/Gesuch aus der dargestellten Liste aus.
Durchzuführende Aktion
Der Anwender wählt das Angebot/Gesuch im entsprechenden Screen aus und kann dieses durch das klicken auf löschen entfernen. Das entfernte Angebot/Gesuch werden per Webservice an den Server übertragen und dort entgültig gelöscht, sodass diese für weitere Anwender nicht mehr angezeigt werden. Angetretene Fahrten oder gerade stattfinde Fahrt kann nicht gelöscht werden.
Erwartetes Ergebnis
Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind.
Tatsächliches Ergebnis
||
Anwendungsfall
F08 Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten
Szenario
Clientseitige Anzeige von gefundenen Übereinstimmungen für Fahrtangebote / Fahrtgesuche
Voraussetzung
Anwender ist am System Registriert. Fahrangebot /Mitfahrgelegenheitsgesuch ist bereits im System eingestellt
Eingangsparameter
Mitfahrtsuche / Mitfahrtangebot sind eingetragen und am System veröffentlicht.
Durchzuführende Aktion
Der Anwender öffnet die Anwendung und meldet sich am System an. In der Vergangenheit hat er bereits Mitfahrtsuchen / Mitfahrtangebote veröffentlicht.
Erwartetes Ergebnis
Die Anwendung zeigt bei gefunder Übereinstimmung das Ergebnis an, sobald der User sich an der Anwendung angemeldet hat. Ist die Anwendung im Hintergrund aktiv und Anwender ist angemeldet, so erscheint in der Statusleiste des Smartphones ein Symbol für die gefundene Übereinstimmung.
Tatsächliches Ergebnis
Anwendungsfall
F09 Bewertungen abgeben
Szenario
Clientseitige Möglichkeit durchgeführte Fahrten zu bewerten
Voraussetzung
Anwender ist am System Registriert. Eine Fahrt wurde durchgeführt.
Eingangsparameter
Der Anwender wählt im Bewerungsbildschirm die durchgeführte Fahrt aus.
Durchzuführende Aktion
Nachdem der Anwender die Fahrt ausgewählt hat, hat er die Möglichkeit weitere Eingaben durchzuführen und anschließend die Fahrt mit Sternen 1-5 zu bewerten. Anschließend bestätigt er seine Eingabe mit OK.
Erwartetes Ergebnis
Wenn der Anwender die Bewertung zum späteren Zeitpunkt erneut aufruft, werden die bereits Eingegebenen Informationen korrekt aufgerufen.
Anwender wählt im entsprechenden Bildschirm das er sein Passwort zurücksetzen möchte.
Durchzuführende Aktion
Nachdem der Anwender ausgewählt hat das er sein aktuelles Passwort zurücksetzen möchte wird ihm durch das System eine generiertes Passwort an seine registrierte Email Adresse zugeschickt.
Erwartetes Ergebnis
Ein vom System generiertes Passwort wird dem Anwender zugeschickt. Mit diesem Passwort kann sich der Anwender am System clientseitig anmelden und daraufhin ein neues Passwort vergeben.
Tatsächliches Ergebnis
Anwendungsfall
F11 Historie von Benutzern
Szenario
Clientseitige Möglichkeit bereits durchgeführte Fahrten und Angebote einzusehen.
Voraussetzung
Anwender ist am System Registriert. Fahrangebot wurden bereits wahrgenommen.
Eingangsparameter
Der Anwender wählt den entsprechende Bildschirm in der Applikation aus.
Durchzuführende Aktion
Nachdem der Anwender den Bildschirm ausgewählt hat, werden die darzustellenden Informationen vom Webserver an den Client gesendet.
Erwartetes Ergebnis
Es werden die vom Anwender durchgeführten Aktionen durchgeführt. Weiterhin ist der Anwender anschließend in der Lage durchgeführte Aktionen zu löschen.
Datenbankzugriff ist möglich. Administrationskennung ist vorhanden.
Eingangsparameter
Administrator meldet sich mit seiner Kennung an der Datenbank an.
Durchzuführende Aktion
Der Administrator kann alle administrative Aktionen durchführen.
Erwartetes Ergebnis
Die definierten administrativen Aktionen sind durchführbar.
Tatsächliches Ergebnis
6.Fachliche Architektur
6.1 Spezifikations-Klassendiagramme -> Oli Klassendiagramm
6.2 Spezifikations-Interaktionsdiagramme -> Oli "Sequenz"
Die folgenden Sequenzdiagramme sind nicht aus den Spezifikationsklassendiagrammen generiert. Grundlage der Erstellung waren die Anwendungsfälle, Architekturüberlegungen und Prototypen der GUI. Es ergibt sich an dieser Stelle also momentan ein Bruch im modellgetriebenen Vorgehen, der sich in der nicht durchgängigen Bezeichnung der Instazen widerspiegelt
Dieser Bruch ist dem nicht-sequentiellen, sondern parallelen und verteiltem Vorgehen innerhalb des Projekts geschuldet, soll an dieser Stelle nicht weiter hinderlich sein.
7. Priorisierte Anforderungsverfolgung zum Lastenheft
Es wird eine stufenweise Realisierung der oben aufgelisteten Anforderungen durchgeführt. Dabei werden die gesamten Anforderungen in drei Releases umgesetzt.
7.1 erstes Release
Im erste Release werden folgende Anforderungen umgesetz:
F01 Registrieung
F02 Anmeldung
F03 Pflege von Profildaten
F04 Mitfahrgelegenheit anbieten
F05 Mitfahrgelegenheit suchen
F06 Mitfahrgesuche anzeigen
F07 Mitfahrgelegenheit/Mitfahrgesuch löschen
F08 Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten
F09 Bewertungen abgeben
F10 Passwort zurücksetzen
O01 Ameldung an der Anwendung über Facebook
O04 Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
Die hier aufgelisteten Anforderungen werden im ersten Release clientseitig implementiert, dabei werden die Webservices am Client durch eine lokale Datenbank simuliert.
7.2 zweites Release
Im zweiten Release werden folgende Anforderungen umgesetzt:
F10 Passwort zurücksetzen
F11 Historie von Benutzern
O02 Auf der Facebookseite des jeweiligen Users werden Fahrtangebote und –gesuche gepostet.
O03 Die aktuelle Position des Nutzers wird auf der zugehörigen Facebookseite aktualisiert
O05 Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden.
Die hier aufgelisteten Anforderungen werden im zweuten Release ebenfalls clientseitig implementiert, dabei werden die Webservices am Client durch eine lokale Datenbank simuliert.
7.3 drittes Release
Im dritten Release erfolgt die serverseitige Implementierung der im ersten Kapitel aufgelisteten Anforderungen. Dabei werden insbesondere die geforderten Webservices umgesetzt. In diesem Release wird die clientseitige Datenbank durch Webservices abgelöst, sodass die Client - Server Kommunikation hergestellt wird.
8 Lieferumfang
Der Lieferumfang des Systems entspricht folgendem Umfang zu den angegebenen Terminen
Lieferumfang
Liefertermin
Lastenheft
02.05.2011
Pflichtenheft
02.05.2011
Architekturentwurf
02.05.2011
Datenbankentwurf
02.05.2011
Designentwurf
27.05.2011
Umsetzung erstes Release (Prototyp)
27.05.2011
Umsetzung zweites Release
01.09.2011
Umsetzung drittes Release
01.02.2011
Testkonzept
27.05.2011
Benutzerdokumentation
15.07.2011
9 Abnahmekriterien
9.1 Voraussetzung für die Abnahme
Voraussetzung für die Abnahme sind die folgenden Bedingungen:
Die Lieferung aller im Abschnitt „Lieferumfang“ definierten Produkte ist zu den angegebenen Lieferterminen zu erfolgt.
Der Prototyp der Clientapplikation ist zum angegeben Liefertermin in einem stabil lauffähigen Umfang zu liefern. Die Grundlegenden Businessprozesse werden im Groben zu erkennen sein.
Alle nichtfunktionalen Anforderungen müssen erfüllt sein und ihre Erfüllung muss durch entsprechende Tests nachgewiesen werden.
Alle nichtfunktionalen Anforderungen müssen erfüllt sein. Ihre Erfüllung ist durch entsprechende Tests nachzuweisen.
Durch Definition und Durchführung entsprechender Testfälle ist die korrekte Umsetzung aller Anwendungsfälle nachzuwesien. Voraussetzung für die Abnahme ist, dass mindestens 95% der Anwendungsfälle korrekt umgesetzt sind.
9.2 Durchführung und Aufbau der Testfälle
Für jeden spezifizierten Anwendungsfall muss mindestens ein Testfall definiert werden. Besteht der Anwendungsfall aus mehr als einem Hauptszenario, sind ebenfalls für die Alternativszenarien Testfälle zu erstellen.Der grundsätzliche Aufbau eines Testfalls orientiert sich dabei an folgender Vorlage, welcher jedoch verfeinert werden kann:
ACHTUNG! Änderungsstopp am 30.04.2011 17:00 Uhr!!
PflichtenheftTODO:
Use-Case ->Oli 23.4 (erledigt)
Sequenzdiagramm mit Ablauf der Prozesse -> (erledigt)
Klassendiagramme ->Oli 23.4 (erledigt)
Pflichtenheft ->23.4
1.Zielbestimmung -> Sebastian
1.1. Musskriterien
Aus dem Lastheft ergeben sich folgende Musskriterien1.1.1 Funktionale Anforderungen
F01 Registrierung
Das Backend muss einen Webservice bereitstellen, über den es möglich ist, dass der neue Benutzer sich ein Benutzerkonto anlegt. Die vom neuen Benutzer eingegebenen Daten müssen durch das Backend persistent abgelegt werden. Der Client für das mobile Endgerät muss eine entsprechenden Maske anbieten, in der der Benutzer alle Pflicht -und optionalen Angaben für das Benutzerkonto eingeben kann. Die Anzeige zum Anlegen eines neuen Benutzerkontos muss die Applikation ermöglichen, ohne dass man sich an der Anwendung anmeldet. Folgende Informationen muss der Werbservice des Backends und die Maske des Clients bei der Erstellung des Benutzeraccounts verarbeiten können:Passwortbidlungsvorschift:
Mindestlänge: 5 Zeichen
1 Sonderzeichen muss enthalten sein
1.1.2 F02 Anmeldung
Bevor ein registrierter Nutzer die Anwendung nutzen kann, muss er sich an der Anwendung mittels Nickname und Passwort oder Emailadresse und Passwort über den Client am Backend anmelden.
1.1.3 F03 Pflege von Profildaten
Das Backend muss einen Webservice zur Vefügung stellen, der eine Profildatenpflege ermöglicht. Über die GUI am Client wird die Pflege der Profildaten realisiert. Die Daten werden im Backend abgespeichert. Folgende Profildaten müssen gepflegt werden können:
Muss mindestens aus 5 Zeichen bestehen
Muss mindestens ein Sonderzeichen beinhalten
1.1.4 F04 Mitfahrgelegenheit anbieten
Der Client bietet eine Oberfläche, mit der es möglich ist alle relevanten Informationen zu einer Mitfahrgelgenheit, die man anbieten möchte anzugeben. Das Backend bietet einen entsprechenden Webservice an, der die Daten entgegennehmen und verarbeiten kann. Folgende Daten können eingegeben werden:
Alternativ muss der Anwender hier auch Sofort auswählen können
Zur Unterstützung des Nutzers kann auf Fahrtangebote zurückgegriffen werden können, welche der Fahrer in der Vergangenheit angeboten hat. Als Startadresse kann der Nutzer seine aktuelle Position übernehmen. Die Position wird dann über die Geolocationsfunktionen des Endgerätes möglichst genau ermittelt.
1.1.5 F05 Mitfahrgelegenheit suchen/Mitfahrgesuch aufgeben
Die Android-Applikation und das Backend realisieren eine Funktion, die es ermöglicht, eine Mitfahrgelgenheit zu suchen. Im Client müssen dazu folgende Informationen angegeben werden:
Die GUI unterstützt den Fahrtsucher bei der Eingabe der Daten anhand von Maskeneingaben aus der Vergangenheit. Auf Wunsch des kann die Startadrasse möglichst genau durch die Geolocationsfunktionen des mobilen Endgerätes ermittelt werden. Wird als Reisebeginn Sofort gewählt, wird als Startadresse immer die aktuelle Position des Nutzers angegeben. Hierzu wird auf Geolocationsfunktionen des mobilen Endgerätes zurückgegriffen.
Das Backend nimmt die Daten entgegen und wertet sie, sodass zur Suche passende Ergebnisse an den Client gesendet werden. Der Client stellt die Ergebnisse in einer Tabelle dar.
Folgende Informationen werden an den Client zurückgeliefert:
bei angetretener Fahrt aktuelle Position des Fahrers
*Es wird nicht die genaue Position des Fahrers übergeben, sodass Stalking erschwert wird.
1.1.6 Mitfahrgesuche anzeigen
Ein Fahrer, der eine Fahrt anbietet und schon eingegeben hat, kann die Möglichkeite nutzen, sich Mitfahrgesuche anzeigen zu lassen, die seiner geplanten Fahrt entsprechen. Für die Suche kann er zuvor eingeben, in welchem Umkreis um seine Startposition oder auch aktuelle Position nach Mitfahrerern gesucht werden soll. Die aktuelle Position wird durch Funktionen des Endgerätes ermittelt. Die Applikation realisiert eine Eingabemaske für den Fahrer um Mitfahrgesuche ermitteln zu können. Die Eingabemaske zeigt zunächst alle geplanten und noch nicht abgeschlossenen Fahrten des Nutzers. Hier kann der Nutzer die Fahrt aussuchen, für die er Mitfahrer suchen möchte. Die Eingabe der gewünschten Umkreissuche wird ermöglicht.
Die Daten der Anfrage werden an das Backend übermittelt. Der Webservice des Backendes muss die Daten vom Client verarbeiten können. Das Backend ermittelt anhand des aktuellen Datenbestandes alle Mitfahrgesuche, die zu der Suche des Fahrers passen und übermittelt das Ergebnis an den den Client.
Der Client stellt die empfangenen Daten in einer Tabelle dar. Folgende Daten werden je potentiellem Mitfahrer präsentiert
oder die aktuelle Position des Suchers
*Um Stalking zu erschweren wird die aktuelle Position des Fahrtsuchers ungenau angezeigt.
Der Nutzer kann sich Profilinformationen und Bewertungen, der User, die in der Ergebnismenge enthalten sind anzeigen lassen.
1.1.7 Mitfahrgelgenheit/Mitfahrgesuch löschen
1.1.7.1 Mitfahrgelegenheit löschen
Die GUI bietet die Möglichkeit angebotene, aber noch nicht angetretene Reiseangebote des eigenen Benutzers zu löschen. Das Backend bietet dazu einen passenden Webservice an. Auf Backendseite wird sichergestellt, dass der angemeldete Benutzer nur seine eigenen Angebote löschen kann.
Die GUI listet in einer Tabelle die noch nicht angetretenen Angebote auf. Folgende Information je Angebot werden dem Nutzer präsentiert:
1.1.7.2 Mitfahrgesuch löschen
Die GUI bietet dem Nutzer die Möglichkeit eigene, eingegebene Reisegesuche zu löschen. Das Backend bietet dazu einen passenden Webservice an. Auf Backendseite wird sichergestellt, dass der angemeldete Benutzer nur seine eigenen Gesuche löschen kann.
Die GUI listet in einer Tabelle die eingegebenen Gesuche auf. Folgende Information je Gesuch werden dem Nutzer präsentiert:
1.1.8 Benachrichtigung bei passenden Reisezielen / Fahrtangeboten
Wenn die Anwendung auf dem Endgerät läuft und der Benutzer angemeldet ist, fragt die Anwendung in regelmäßigen Intervallen bei dem Backend an. Hat der Nutzer ein Mitfahrgesuch oder eine Mitfahrangebot auf dem Server veröffentlicht, ermittelt der Server bei jeder Anfrage des Endgerätes, ob entsprechende Angebote oder Gesuche eingegeben wurden und übermittelt diese an das Endgerät. Ist die Anwendung auf dem Endgerät im Vordergrund, so werden die gefundenen Ergebnisse sofort auf dem Bildschirm angezeigt. Die Anzeige erfolgt in einer Tabelle wie in 1.1.5 und 1.1.6 beschrieben. Befindet sich die Anwendung im Hintergrund, so wird bei neu gefundenen Ergebnissen ein Symbol in der Statusleiste des Endgerätes angezeigt.
1.1.9 Bewertung abgebgen
Der Client bietet über eine Maske eine Bewertungsmöglichkeit. Auf der Bewertungsmaske werden alle anderen Nutzer angezeigt, für die man eine Bewertung abgeben kann. Je möglicher Bewertung wird eine Tabellenzeile angezeigt. Folgende Inhalte hat jede Zeile:
Durch Antippen der Zeile kann für diese Fahrt eine Bewertung eingegeben werden. Es wird eine weitere Maske geöffnet. In dieser Maske kann ein Freitext von 255 Zeichen eingegeben werden. Darüberhinaus kann eine Punktzahl (1-5) für die Bewertung angegeben werden, wobei 5 die höchste Wertigkeit darstellt.
Bedingungen für die Bewertung eines anderen Nutzers:
Eine Bewertung eines anderen Nutzers ist nur dann möglich, wenn der bewertende Nutzer und der zu bewertende Nutzer in unterschiedlichen Rollen an der gleichen Fahrgemeinschaft teilgenommen haben.
Bis zu 1 Monat nach Beendigung einer gemeinsamen Fahrt ist eine Bewertung möglich.
Das Backend liefert dem Client die Daten für die Auswahltabelle der Bewertung. Es liefert nur die Daten, die für den angemeldeten/anfragenden Nutzer relevant sind. Das Backend stellt einen Webservice zur Verfügung, der die Bewertungsinformationen für einen Nutzer (Freitext, Punktzahl) entgegennehmen kann. Die Bewertungsinformationen werden in der Datenbank abgelegt. Das Backend stellt sicher, dass die weiter oben beschriebenen "Bedingungen für die Bewertung eines anderen Nutzers" eingehalten werden.
1.1.10 Passwort zurücksetzen
Die GUI realisiert die Möglichkeit das Passwort eines Nutzers zurücksetzen zu lassen. Zur Rücksetzung wird die Emailadresse benötigt, mit welcher der Nutzer registriert ist.
Das Backend realisiert einen Webservice, der die Emailadresse von der Clientanwendung entgegennimmt. Im Backend wird dann ein neues Passwort generiert, bei den Userdaten abgespeichert und an die Emailadresse des Nutzers gesendet.
1.1.11 Historie eines Benutzers
Die GUI bietet einen Screen, mit dem es dem angemeldeten Nutzer möglich ist alle seine Mitfahrgesuche, Mitfahrangebote und genutzte Mitfahrgelgenheiten anzuzeigen. Je nach Displaygröße des Endgerätes wird nur ein Teil angezeigt. Durch klicken auf Mehr können weitere historische Einträge abgerufen werden. Aus diesem Screen heraus ist es möglich, nicht mehr gewünschte Angebote und Gesuche zu löschen (siehe 1.1.7).
Das Backend stellt der Clientanwendung die Daten bereit. Der Webservice des Backendes wird so implementiert, das nur die vom Client angefrangte Menge von historischen Einträgen übermittelt wird.
1.1.12 Administrative Eingriffe
Die administrativen Eingriffe erfolgen direkt auf der Datenbank. Es werden entsprechende Views, Funktionen und Skripte auf der Datenbank realisiert, um folgende Funbktionen zur Administration zu ermöglichen:
1.1.13 Anzeige von Profilinformationen eines anderen Nutzers
Verschiedene Fälle der Anwendung erfordern es, dass ein Nutzer das Profil eines anderen Nutzers einsehen kann, z.B. bei dem Use-Case "Mitfahrgelgenheit suchen" muss der Benutzer sich die Profilinformationen des Fahrtanbieters anschauen können um zu entscheiden, ob er mit dem Fahrer mitfahren möchte und um Kontakt aufzunehmen.
Der Webservice der Anwendung sendet die Profilinformationen an den Client. Das Backend stellt sicher, dass eine Massenauslesung der Profilinformationen nicht möglich ist. Der Client kann nur die Profile abrufen, die innerhalb seines aktuellen Use-Cases für ihn relevant sind.
Beispiel Use-Case Fahrten suchen:
In der Client-Anwendung werden über die GUI die Profilinformationen angezeigt.
Folgende Profildaten werden vom Backend gesendet und vom Client angezeigt:
1.1.14 Anzeige von Bewertungen
Verschiedene Fälle der Anwendung erfordern es, dass ein Nutzer die Bewertungen eines anderen Nutzers einsehen kann, z.B. bei dem Use-Case "Mitfahrgelgenheit suchen" dienen diese als Entscheidungshilfe für den Mitfahrer, ob er mit einem Fahrer eine Fahrgemeinschaft eingehen möchte
Der Webservice der Anwendung sendet die Bewertungen des entsprechenden Nutzers an den Client. Das Backend stellt sicher, dass eine Massenauslesung der Bewertungen nicht möglich ist. Der Client kann nur die Bewertungen abrufen, die innerhalb seines aktuellen Use-Cases für ihn relevant sind.
Beispiel Use-Case Fahrten suchen:
In der Client-Anwendung werden über die GUI die Bewertungen angezeigt.
Folgende Bewertungsinformationen werden vom Backend gesendet und vom Client angezeigt:
Beispiel:
Anzahl von Bewertungen pro Seite = 7
1.1.2.1 Standardschnittstellen
Das Backend verwendet zur Kommunikation mit dem Client standardisierte Protokolle und Schnittstelle, damit auch andere mobile Endgeräte als Android angebunden werden können.
1.1.2.1 Bedienungsoberfläche
Die Bedienungsoberfläche wird selbsterklärend gestaltet, eine Bedienung mittels Touchscreen wird ermöglicht.
1.2. Wunschkriterien
1.2.1 Ameldung an der Anwendung über Facebook
1.2.2 Posting vo nFahrtangebote und –gesuche aufder Facebookseite des jeweiligen Users
1.2.3 Aktualisierung der Position des Nutzers auf der zugehörigen Facebookseite
1.2.4 Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
1.2.5 Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden
1.3. Abgrenzungskriterien
1.3.1 Oberfläche für Geräte der Smartphoneklasse
Die Oberfläche wird für Androidgeräte mit einem Display von bis zu 5 Zoll entwickelt. Die Anwendung ist auf Tablet-PC mit Android-Betriebssystem lauffähig, aber wird nicht für die größeren Displays optimiert.
1.3.2 Einsatzort
Die Applikation und das Backend werden für den Einsatz in Deutschland entwickelt.
2. Produkteinsatz
Im folgenden Abschnitt wird auf den Produkteinsatz der Applikation eingegangen. Dabei wird im Anwendungsbereich der Zweck der Applikation erläutert. Bei den Zielgruppen geht es darum zu erläutern, welche Personen mit welchen Qualifikationen die Anwendung nutzen sollen und bei den Betriebsbedingungen geht es darum, diese zu erläutern.[[#_ftn1|[1]]][[#_ftnref1|[1]]] Vgl. http://www.stefan-baur.de/downloads/Pflichtenheft.pdf (23.04.2011, 12:50 Uhr).
- 2.1. Anwendungsbereiche
Die Anwendung wird von einzelnen Personen zur Suche von Mitfahrgelegenheiten und zum Bekanntmachen einer Fahrt genutzt. Dem Anwender wird es so ermöglicht, Kosten zu sparen, indem er sich an einer Fahrt beteiligt oder selbst eine Fahrt tätig und hier andere Nutzer mitnimmt.- 2.2. Zielgruppen
Zur Ziel gehören, die im Lastenheft erörterten Personen. Die Anwender sollten ein Smartphone mit Internetzugang und dem Betriebssystem Android besitzen. Weiterhin sollten Kenntnisse im Umgang mit dem Umgang von Smartphone Applikationen vorhanden sein. Da die Software in deutscher Sprache umgesetzt wird, sollte der Anwender diese Sprache beherrschen.- 2.3. Betriebsbedingungen
Hinsichtlich der Betriebsbedingungen orientiert sich die Anwendung an den üblichen Bedingungen von Smartphone Applikationen und Webservices:[[#_ftn1|[1]]]- Betriebsdauer: 24 Stunden täglich
- Wartungsfrei
- Keine ständige Beobachtung des Systems nötig
[[#_ftnref1|[1]]] Vgl. http://www.stefan-baur.de/downloads/Pflichtenheft.pdf (23.04.2011, 12:50 Uhr).
3. Produktumgebung
3.1.1.Software
Für die Android Endgeräte wird die Betriebssystemversion 2.1 Codename Eclair verwendet. Durch die Verwendung dieser Version können laut der unten zu sehenden Grafik bis zu über 90% aller Android Usern durch die AppFahrt unterstützt werden. Somit würde im Gegensatz zur Implementiertung für eine höhere Androidversion wie beispielsweise 2.3 ein höhere Abdeckung möglich sein, da Apps grundsätzlich abwärtskompatibel sind.Quelle (http://developer.android.com/resources/dashboard/platform-versions.html .- Stand 25.04.2011)
Im Gegensatz zur Version 2.2 weist die aktuelle Version 2.3 Codename Gingerbread keine für diese Applikation nennenswerte Vorteile, sodass diese ausgeschlossen werden kann.
3.1.2 Oberfläche
Um die geforderten Anforderungen benuterfreundlich zu realisieren werden folgende Oberflächen in der Android App realisiert.- App Start
- ProfilerstellenFacebook Login
- Facebook Aktionen - Login
- Map
- Map - Fahrt antreten
- Map - Fahrt suchen
- Map - Fahrt bewerten
Detailierte Beschreibung sowie Abbildungen erfolgen im Kapitel Benutzungs- und Systemschnittstellen.3.1.3 Verwendete Softwarekomponenten
Für die Entwicklung der clientseitigen Applikation werdne folgende Komponenten eingesetzt:
als Programmiersprache Java
als Entwicklungsumgebung Eclpise Helios Service Release
Andorid SDK für Eclipse
3.2. Hardware
Die Applikation ist so konzepiert, dass diese auf allen Smartphones mit der Betriebssystemversion 2.1 Codename Eclair lauffähig ist. Grundsätzlich ist die haupt Androidplattform die ARM ArchitekturDer größte Vorteil der ARM Architektur ist die geringe Leistungsaufnahme, wodruch diese Architektur insbesondere für mobile Endgeräte eingesetzt wird. (Quelle http://en.wikipedia.org/wiki/Android_%28operating_system%29#Hardware_running_Android)
3.4 Voraussetzung für die Nutzung der Applikation
Für die Nutzung der Applikation ist sowohl eine Internetverbindung als auch GPS Verbindung zwingend notwendig. Die Internetverbindung ist sowohl für die Verbindung zum Webserver der Anwendung notwendig als auch für die Verbindung zu den Servern von CloudMade und OpenStreetMap.Durch eine aktive GPS Verbindung ist die Ermittlung der aktuellen Position möglich. Weiterhin werden die GPS Koordinaten serverseitig benötigt, um die notwenidgen Berechnungen durchführen zu können und potentielle Mitfahrer und Fahrer zu verbinden.
3.4. Produkt – Schnittstellen
Die clientseitige Applikation verfügt über Webserviceschnittstellen, die für die Kommunikation zum Webserver dienen. Darüberhinaus ist eine Schnittstelle zum Facebookdienst vorhanden. Die Anwendung immplementiert die Facebook API und greift über das Internet auf die Facebook Webserver zu und ermöglicht so die Nutzung der zu Verfügung gestellten Services.Weiterhin nutzt die clientseitige Anwendung den Webservice von Cloudmade und Open Street Map für die Darstellung der aktuellen Positon auf der Karte.
4. Akteure und Anwendungsfälle
4.1 Akteure
Für das System AppFahrt werden vier Akteure modelliert. Die Akteure Mitfahrer, Fahrer und Adminstrator sind eine Generalisierung des Akteurs Anwender, der einen generische Akteur darstellt.
Nachfolgend eine Kurzbeschreibung der vier Akteure:
4.2 Use Case Überblick
Im weiteren Verlauf der Spezifikation und Entwicklung werden zur Wahrung des Projektrahmens nur die Anwendungsfälle des Pakets"Fahrt planen und durchführen" weiter betrachtet. Die charakteristischen Funktionen des Systems AppFahrt sind in diesem Paket enthalten.
Anwendungsfälle der weiteren Pakete Userprofil verwalten und Administration enthalten Funktionalitäten, so z.B. der Anwendungsfall Userprofil bearbeiten, die in herkömmlichen IT-Systemen enthalten sind und an dieser Stelle nicht detailiert beschrieben werden müssen, wenngleich sie für die Umsetzung des Gesamtsystems notwendig sind.
4.2.1 Fahrt planen
Fahrer ist am System angemeldet.
2. Der Fahrer gibt den Endpunkt der Fahrt ein.
3. Das System macht einen Vorschlag für den Fahrpreis. Der Fahrer gibt den Fahrpreis an.
4. Der Fahrer gibt einen Starttermin der Fahrt an (Datum und Uhrzeit).
5. Der Fahrer gibt die Anzahl der freien Plätze an.
6. Der Fahrer veröffentlicht die Fahrt.
7. Das IT-System bietet die Möglichkeit eine Rückfahrt einzugeben.
4. Der Fahrer gibt als Starttermin "Sofort" ein.
4.2.2 Mitfahrwunsch angeben
Standardablauf: Es existiert bereits eine passende Fahrt, die der Mitfahrer auswählen kann.
Alternative Ablaufschritte: Es gibt keine passende Fahrt. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch, mit dem Ziel, dass sich ein Fahrer dazu findet.
In diesem Use Case können auch Mitfahrwünsche für bereits aktiven Fahrten (D.h. die Fahrt ist bereits angetreten) angegeben werden. Die Anzeige bzw. Auswahl von aktiven Fahrten ist abhängig von den einzugebenen Suchkriterien (Abfahrtort, Abfahrttermin) einer Fahrt.
Mitfahrer ist am System angemeldet.
2. Das IT-System liefert den Suchkriterien entsprechende Fahrten zur Auswahl zurück.
3. Der Mitfahrer wählt eine Fahrt aus.
4. Der Mitfahrer äußert seinen Mitfahrwunsch gegenüber dem Fahrer.
3. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch mit den in den Suchkriterien angegebenen Attributen (Startpunkt, Endpunkt, Termin).
4. Der Mitfahrer gibt einen Fahrpreis an.
4. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch. Der Mitfahrwunsch ist für Fahrer sichtbar.
4.2.3 Mitfahrwunsch annehmen
Dabei ist es unerheblich, ob die Fahrt noch geplant oder bereits aktiv ist.
Fahrer hat ein Userprofil.
Fahrer ist am System angemeldet.
2. Der Fahrer kontaktiert den Mitfahrer.
3. Der Fahrer bestätigt den Mitfahrwunsch. Die Anzahl freier Plätze wird aktualisiert.
4. Der Mitfahrer erhält eine Bestätigung der Mitfahrt per Email/ SMS.
4.2.4 Fahrt antreten und tracken
Fahrer hat ein Userprofil
Fahrer ist am System angemeldet.
2. Fahrer aktualisiert die Anzahl der freien Plätze.
3. Fahrer startet seine Fahrt.
4. Die Position des Fahrers wird geändert und zyklisch aktualisiert.
5. Der Fahrer beendet die Fahrt.
26.04.2011, OW Erweiterung.
4.2.5 Fahrt bewerten
Fahrer hat ein Userprofil
Fahrer ist am System angemeldet.
2. Fahrer klick auf "Fahrt bewerten".
3. Fahrer vergibt Bewertungspunkte für einen Mitfahrer.
4. Fahrer schreibt als Bewertung einen Freitext.
5. Fahrer klickt auf "Bewertung absenden"
4.2 Domänen-Klassendiagramme ->Marcel + Sebastian
Das nachstehende Klassendiagramm stellt alle Gegenstände dar, die im Rahmen der geforderten Anwendungsfälle Verwendung finden. Anhand der vorgegebenen Sturktur mit Klassen und Attributen soll die Entwicklung der Anwendung durchgeführt werden. Die aufgezigten Klassen samt Attributen sollen als Basis für den Entwurf genutzt werden, in dem weitere Attribute und vor allem Methoden an den Klassen ergänzt werden müssen, die für die Anwendung benötigt werden.4.3 Benutzungs- und Systemschnittstellen -> Aleks
4.3.1 Android Applikation - Gui
App Start
Beim erstmaligen Start der Applikation wird das AppFahrt Logo dargestellt. Das Logo soll die Applikation einleiten. Nach einigen Sekunden wird das Logo ausgebledet und der Login Screen erscheint. Das Logo erscheint wie bereits erwähnt beim erstmaligen Start der Anwendung. Befindet sich die Anwendung bereits im RAM Speicher des Smartphones erscheint sofort das Login Screen. Wird die Anwendung jedoch vom Android Betriebssystem aus dem RAM entfernt und die Anwendung zum späterem Zeitpunkt gestartet, so wird das Logo wieder dargestellt.
Login Screen
Der Login Screen ermöglich wie der Name bereits aussagt das Einloggen eines Benutzers in die Applikation. Hierfür trägt der Anwender seine Email und Passwort in die entsprechenden Felder ein. Die Anmeldedaten werden verefiziert und beim erfolgreichen verefizieren der eingegebenen Daten wird die Map angezeigt. Sind die eingegebenen Daten jedoch fehlerhaft, wird durch eine Meldung der User darauf hingewiesen und die Map wird nicht dargestellt.
Enthält der Benutzer noch kein Useraccount für diese Applikation kann dieser durch das auswählen des Profil erstellen Buttons ein Profil für die Applikation anlegen. Weiterhin hat der Anwender die Möglichkeit sich durch sein Facebook Account an der Anwendung anzumelden. Zum Facebook Login Screen gelangt der Anwender durch das klicken auf den Facebook Button.
Profilerstellen
Falls noch kein Profil für die Applikation vorhanden ist, kann der Anwender wie bereits erwähnt ein Profil erstellen. Der Kontakdaten Screen enthält Eingabefelder für die Eingabe notwendiger Informationen für das Profil.
Welche Pflichtfelder befüllt werden müssen, um die einmalige Profilerstellung erfolgreich abzuschließen, kann dem Kaptitel 1.1.1 Funktionale Anforderung entnehmen.Wird ein Pfichtfeld nicht befüllt so erscheint eine Meldung mit dem Pflichtfeld / Pflichtfeldern die noch auszufüllen sind, um das Profil erfolgreich zu erstellen.
Facebook Login
Möchte man sich mit deinem Facebook Account an der Applikation anmelden, so drückt der Benutzer auf das Facebook Icon Button. Nach dem Klicken verändert sich die Farbe des Icons von blau nach grau. Anschließend erscheint der Facebook Login Screen.
Facebook Aktionen - Login
Hier hat der User zunächst die Möglichkeit sich durch das klicken auf den Login Button mit seinem Facebook Logindaten anzumelden.
Es erscheint der Facebook-Anmeldung Bildschirm, wo der Anwender seine Facebook Logindaten eingeben kann und anschließend mit Anmelden bestätigen.
Im nächsten Screen, dem Anfrage für Genehmigung Bildschirm, wird der Anwender aufgefordert durch das Klicken auf den Button Zulassen einige Berechtigung für die Anwendung freizugen. Diese Berechtigung sind notwendig, damit die Anwendung unter anderem auf die Emailadresse des Anwenders zugreifen kann, um diese in die eigene Datenbank abzuspeichern, ähnlich wie beim erstellen eines Profils für die Anwendung.
Nach dem erfolgreichen Anmelden am Facebook ist der Anwender in der Lage, durch das klicken auf den Button Post beispielsweise seine geplante Fahrt auf seine Pinwand zu posten. Seine Facebook Freunde sowie die Freunde von AppFahrt bekommen dadurch im Voraus mit welche Fahrt der Anwender plant und können somit den Anwender direkt kontaktieren um ggf. mitfahren zu können.
Map
Nachdem erfolgreichen anmelden an Applikation öffnet sich der Map Screen. Es wird die aktuelle Position des Anwenders angezeigt. Die aktuelle Position wird an Hand der GPS Daten ermittelt. Durch das klicken auf die Manü Taste des jeweiligen Smartphones öffnen sich in der unteren Leiste view Menüoptionen.
Map - Fahrt antreten
Wie bereits erwähnt durch das klicken auf den Button Fahrt erstellen... erscheint das Fahrtantritt Screen. Hier kann der Anwender eine spontante Fahrt erstellen. Kapitel 1.1.4 Kann man die Pflichtfelder hierfür entnehmen.
Map - Fahrt suchen
Wie bereits erwähnt durch das klicken auf den Button Fahrt suchen... erscheint das Fahrtgesuch Screen. Hier kann der Anwender nach Fahrten suchen. Kapitel 1.1.5 Kann man die Pflichtfelder hierfür entnehmen.
Map - Fahrt bewerten
Durch das klicken auf den Button Fahrt bewerten... erscheint der Fahrtbewertung Screen. Hier kann hat der Anwender die Möglichkeit seine Fahrten zu bewerten gemäß der Anforderung im Kapitel 1.1.9.
4.3.2 Android Applikation - Schnittstellen
Android Applikation enthält Schnittstellen zu4.3.3 Webserver - Schnittstellen
Der Webserve enthält Schnittstellen zu5.Nicht-Funktionale Anforderungen
5.1 Qualitätsanforderungen -> Aleks(test) + Marcel (technische qualitätssicherung z.b. Zeiten)
TODO:Hier sollten wir auch auf Tests eingehen5.1.1 Performance
Anhand von reproduzierbaren Messungen soll die Performance bewertet werden. Folgende Anwendungsfälle müssen in besteimmten Zeitrahmen durchgeführt werden können:Die Verarbeitung der Daten auf dem Client darf maximal zwei Sekunden in Anspruch nehmen.
5.1.2 Skalierbarkeit
Da die Akzeptanz und somit die Anzahl der gleichzeitig aktiven Benutzer nicht absehbar ist, muss das Backend skalierbar ausgelegt sein. Das Backend muss minimal Anfragen von 100 aktiven Nutzern in der definierten Antwortzeit bearbeiten können. Das System muss flexibel ausgelegt sein, so dass durch hinzunahme weiterer Hardware, Anfragen von bis zu 10.000 aktiven Nutzern in der vorgegebenen Antwortzeit bearbeitet werden können.Um Anschaffungs- und Betriebskosten zu sparen soll das System zunächst für 100 aktive Nutzer ausgelegt sein.
Durch die definierten Anforderungen an Performance und Skalierbarkeit werden im Laufe der Entwicklung und der Integrationstests die Anforderung an die Hardware, das Sizing, abgeleitet. Hier wird die Prognose des Wachstums mit einfließen.
Wird ein Performance-Engpass am Client festgestellt, so ist durch einen dynamischen Prozess sicherzustellen, dass ausreichend Ressourcen für diese Anwendung vom Clientbetriebssystem reserviert werden. Ist das beschaffen zusätzlicher Ressourcen vom Clientbetriebssystem nicht möglich, so ist der Benutzer durch eine Meldung über den Ressourcen-Engpass zu informieren.
5.1.3 Verfügbarkeit
Im Lastenheft ist gefordert, dass die Anwendung als hochverfügbar ausgelegt sein muss. In diesem Zusammenhang muss bei der Auswahl des Backendsystems darauf geachtet werden, dass die einzelnen Komponenten diese Anforderung erfüllen. Zu diesem Zweck sollte die Serveranwendeung auf mehreren Instanzen zur Verfügung stehen. Der Client hat dann die Möglichkeit über einen Loadbalancer auf den Server zuzugreifen.Für etwaige Systemausfälle müssen Backups der Produktivdaten gesichert werden. Das Backup muss sämtliche Applikationsdaten bis zu dem entstandenen Fehlerfall wiederherstellen können.
5.2 Sicherheit
Sämtliche Daten der Anwendung müssen vor unbefugtem Zugriff geschützt sein. Zu diesem Zweck muss die Übertragung von personenbezogenen Daten zwischen dem Client und dem Backend verschlüsselt erfolgen. Daten dürfen nicht Massenweise ausgelesen werden können. Böswillige Attacken werden unterbunden.Das Backend muss vor eventuellem Hackerangriffen geschützt sein. Denial of Service Attacken müssen verhindert werden.
Es muss sichergestellt werden, dass der Client ausschließlich mit den definierten Endpunkten kommuniziert. Man in the middle Attacken dürfen nicht möglich sein.
5.3 Testkonzept
Im Kapitel Abnahmekriterien des Lastenhefts wird gefordert, dass die nicht- und funktionale Anforderungen durch Tests nachgewiesen werden.||
6.Fachliche Architektur
6.1 Spezifikations-Klassendiagramme -> Oli Klassendiagramm
6.2 Spezifikations-Interaktionsdiagramme -> Oli "Sequenz"
Die folgenden Sequenzdiagramme sind nicht aus den Spezifikationsklassendiagrammen generiert. Grundlage der Erstellung waren die Anwendungsfälle, Architekturüberlegungen und Prototypen der GUI. Es ergibt sich an dieser Stelle also momentan ein Bruch im modellgetriebenen Vorgehen, der sich in der nicht durchgängigen Bezeichnung der Instazen widerspiegelt
Dieser Bruch ist dem nicht-sequentiellen, sondern parallelen und verteiltem Vorgehen innerhalb des Projekts geschuldet, soll an dieser Stelle nicht weiter hinderlich sein.
6.2.1 Fahrt planen
6.2.2 Fahrt antreten und tracken
6.2.3 Mitfahrwunsch angeben
6.2.4 Mitfahrwunsch annehmen
6.2.5 Fahrt bewerten
7. Priorisierte Anforderungsverfolgung zum Lastenheft
Es wird eine stufenweise Realisierung der oben aufgelisteten Anforderungen durchgeführt. Dabei werden die gesamten Anforderungen in drei Releases umgesetzt.7.1 erstes Release
Im erste Release werden folgende Anforderungen umgesetz:- F01 Registrieung
- F02 Anmeldung
- F03 Pflege von Profildaten
- F04 Mitfahrgelegenheit anbieten
- F05 Mitfahrgelegenheit suchen
- F06 Mitfahrgesuche anzeigen
- F07 Mitfahrgelegenheit/Mitfahrgesuch löschen
- F08 Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten
- F09 Bewertungen abgeben
- F10 Passwort zurücksetzen
- O01 Ameldung an der Anwendung über Facebook
- O04 Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
Die hier aufgelisteten Anforderungen werden im ersten Release clientseitig implementiert, dabei werden die Webservices am Client durch eine lokale Datenbank simuliert.7.2 zweites Release
Im zweiten Release werden folgende Anforderungen umgesetzt:- F10 Passwort zurücksetzen
- F11 Historie von Benutzern
- O02 Auf der Facebookseite des jeweiligen Users werden Fahrtangebote und –gesuche gepostet.
- O03 Die aktuelle Position des Nutzers wird auf der zugehörigen Facebookseite aktualisiert
- O05 Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden.
Die hier aufgelisteten Anforderungen werden im zweuten Release ebenfalls clientseitig implementiert, dabei werden die Webservices am Client durch eine lokale Datenbank simuliert.7.3 drittes Release
Im dritten Release erfolgt die serverseitige Implementierung der im ersten Kapitel aufgelisteten Anforderungen. Dabei werden insbesondere die geforderten Webservices umgesetzt. In diesem Release wird die clientseitige Datenbank durch Webservices abgelöst, sodass die Client - Server Kommunikation hergestellt wird.8 Lieferumfang
Der Lieferumfang des Systems entspricht folgendem Umfang zu den angegebenen TerminenLieferumfang
Liefertermin
9 Abnahmekriterien
9.1 Voraussetzung für die Abnahme
Voraussetzung für die Abnahme sind die folgenden Bedingungen:9.2 Durchführung und Aufbau der Testfälle
Für jeden spezifizierten Anwendungsfall muss mindestens ein Testfall definiert werden. Besteht der Anwendungsfall aus mehr als einem Hauptszenario, sind ebenfalls für die Alternativszenarien Testfälle zu erstellen.Der grundsätzliche Aufbau eines Testfalls orientiert sich dabei an folgender Vorlage, welcher jedoch verfeinert werden kann: